[00:04.920 --> 00:09.380]  Hi, my name is Brandon Bailey. I work within the Cybersecurity Subdivision at the Airspace
[00:09.380 --> 00:15.300]  Corporation and we're excited to be here today in conjunction with the Space ISAC and the
[00:15.300 --> 00:19.680]  Airspace Village to be discussing the topic on some spacecraft research that we've been
[00:19.680 --> 00:26.540]  working on specifically related to exploitation of some of the implementations upon the spacecraft.
[00:26.540 --> 00:31.880]  So we'll jump right into it. I would like to refer people to the paper linked in the front
[00:31.880 --> 00:37.800]  for more information about how you can apply certain cybersecurity controls for a spacecraft.
[00:37.800 --> 00:44.740]  So from an introduction perspective, when you look at vulnerabilities in information systems,
[00:44.740 --> 00:51.220]  particular satellites, they're often overlooked in the wider discussions when you talk about
[00:51.220 --> 00:57.380]  critical infrastructure, but that's changing quite rapidly currently where there's a lot more
[00:57.380 --> 01:02.800]  people discussing spacecraft vulnerabilities, ground system vulnerabilities, and how it relates
[01:02.800 --> 01:06.900]  to our critical infrastructure as a country. So there's been a lot of misunderstanding and
[01:06.900 --> 01:13.260]  somewhat complacency in this regard because there's been a lack of real-life events that's
[01:13.260 --> 01:21.160]  known in the public space of attacks against space vehicles. But the space systems are similar to
[01:21.160 --> 01:27.560]  other systems. One that you would kind of know about is the industrial control systems or
[01:27.560 --> 01:33.160]  operational technology field. So you see some good parallels that can be drawn between the spacecraft
[01:33.160 --> 01:40.680]  and the space systems arena with that. So malicious insiders, external threats,
[01:40.680 --> 01:46.920]  splotching threats, those are all various threat factors that people can get in to affect
[01:46.920 --> 01:53.800]  spacecraft from the sensors to the data being uplinked or downlinked. So there's a lot of
[01:53.800 --> 01:59.660]  different areas where you could have impact that could disrupt military, government,
[01:59.660 --> 02:07.180]  or even commercial activity for our day-to-day activities. So the threats are changing quite
[02:07.180 --> 02:14.140]  rapidly in this arena. So there's a lot more knowledge about space and things of that nature.
[02:14.780 --> 02:20.820]  And then when they would have happened, there'd be an absence of warning. So you know there's
[02:20.820 --> 02:25.560]  not real-time consistent communication between ground and space a lot of times. So
[02:25.560 --> 02:31.660]  there could be times where you're not aware that there's attacks ongoing. And attribution is
[02:31.660 --> 02:36.860]  difficult in the IT world and it's even more difficult in the space world. And there definitely
[02:36.860 --> 02:40.360]  needs to be more research in this area. And that's one of the reasons why we're
[02:41.240 --> 02:45.400]  presenting this material. And I'm assuming one of the reasons why the Aerospace Village
[02:45.960 --> 02:50.080]  exists is because there's a lot more collaboration and research that needs to happen
[02:50.080 --> 02:56.720]  in this arena. And the CubeSat arena is just exploding as we all know. And the barrier to
[02:56.720 --> 03:03.500]  entry into space is being reduced quite extensively. So the good thing is in recent years there's been
[03:03.500 --> 03:10.080]  some open source technology that's been put out there that can help people learn more about space,
[03:10.080 --> 03:16.620]  space protocols, things like that. So Cosmos, which is linked here, NASA's CoreFlight executive
[03:16.620 --> 03:23.840]  or CoreFlight software, OpenSatKit was put out by NASA to help people get started with CubeSats.
[03:24.560 --> 03:30.360]  NOS3 was put out by NASA's Independent Verification and Validation Program to help people build
[03:30.360 --> 03:35.060]  simulators for space. So there's a lot of good open source material out there now. So people
[03:35.060 --> 03:40.060]  can actually start researching this for themselves, which is great. But I will caveat that with
[03:40.060 --> 03:45.680]  one thing is please change your default configs if you're pulling the CoreFlight executive or
[03:45.680 --> 03:50.640]  CoreFlight software from GitHub and running it accordingly. You want to make sure that
[03:50.640 --> 03:57.400]  you can change those default configs. So let's move on to some basics. So for people who aren't
[03:57.400 --> 04:02.660]  necessarily living and breathing space communications and commanding and telemetry
[04:02.660 --> 04:07.240]  and that terminology, here's just an introduction slide to kind of explain what we're talking about.
[04:07.240 --> 04:13.940]  Command and Data Handling or referred to as CDH is essentially how data is relayed to and from
[04:13.940 --> 04:18.340]  the spacecraft. So that's where the encoding and decoding happens for the commands and the
[04:18.340 --> 04:24.580]  telemetry. There's kind of generically four pieces of a space system. You have the user
[04:24.580 --> 04:31.020]  terminal where you do the commanding and the telemetry and process telemetry that runs
[04:31.020 --> 04:35.640]  the ground software. There's some sort of front-end processor that does the conversions of the
[04:35.640 --> 04:41.880]  information from the ground system to get it connected to a modem or an antenna that you can
[04:41.880 --> 04:47.820]  send the information to the spacecraft and get it back down. So from a cyber perspective,
[04:48.660 --> 04:54.720]  the attack surface is quite large because there's a lot of standard IT equipment in there. You know,
[04:54.720 --> 04:58.480]  like with the ground terminals, the front-end processors, there's a lot of operational
[04:58.480 --> 05:02.860]  technology, industrial control systems that operate within these facilities that run these
[05:02.860 --> 05:09.980]  systems or control the antennas. And of course the RF link is the obvious one. So something to
[05:09.980 --> 05:15.560]  note on this diagram is the bulk encryption component is kind of left out for people that are
[05:15.560 --> 05:22.960]  more accustomed to satellite communication where you have cryptos on each end. So I left that out
[05:22.960 --> 05:30.700]  just for ease, for simplicity, but sometimes you do have that bulk encryption there in the middle.
[05:31.440 --> 05:35.640]  And this is just a quick animation of kind of what this looks like where
[05:35.640 --> 05:41.660]  the user would say turn this heater on and then the software translates that to some, you know,
[05:41.660 --> 05:47.180]  hex numbers and then it gets converted by the front-end processor to get framed appropriately
[05:47.180 --> 05:52.640]  and sent to the modem to get modulated up to the bird and back down. So that's just a simple
[05:52.640 --> 05:59.440]  animation to kind of articulate what we're talking about here. And slide five here is something, a
[05:59.440 --> 06:04.800]  paper that was put out by NASIC, the National Air and Space Intelligence Center, which is a pretty
[06:04.800 --> 06:10.880]  good resource if you want to understand the high-level architecture of space systems and
[06:11.440 --> 06:17.160]  where cyber threats could have an impact and the types of cyber threats there are. So
[06:17.730 --> 06:24.150]  in this diagram it's basically just outlining that you have the user segment where you have the
[06:24.750 --> 06:29.490]  the ground software terminals and then the interacts with the ground segment where you
[06:29.490 --> 06:35.010]  have the antennas at times or in the link segment with the RF and the space segment for space. So
[06:35.730 --> 06:39.730]  vulnerabilities exist in all these segments and there's cyber threats within all these segments.
[06:40.090 --> 06:44.050]  Obviously, you know, the user segment is the highest likelihood for a cyber attack given
[06:44.630 --> 06:48.990]  that it may have some level of internet connection where it's operated by people and
[06:48.990 --> 06:55.150]  we understand as being a security researchers or pin testers or red teamers that the people
[06:55.150 --> 07:01.890]  are generally the weakest link in the cyber paradigm. So the user segment is one of the easier
[07:01.890 --> 07:06.950]  areas to get in. But we're going to focus more on the space segment and the link segment
[07:06.950 --> 07:12.590]  specifically because that's where there's less research and less publicized information. So we're
[07:12.590 --> 07:19.450]  going to focus on three types of attacks today with some demonstration screenshots and to discuss
[07:19.450 --> 07:24.590]  how they work, what they are, and how you can mitigate these things. So we're going to talk
[07:24.590 --> 07:32.990]  about a replay attack, which is where you record the command signal and replay it to the vehicle
[07:32.990 --> 07:39.130]  and see if it processes it. So we'll do that and we'll talk about command link intrusion where you
[07:39.130 --> 07:44.630]  basically simulate modulating your own signal to a satellite and seeing if it processes
[07:44.630 --> 07:49.530]  those commands. And then we'll do a denial of service where you could do some GPS jamming
[07:50.230 --> 07:54.270]  to maybe cause the denial of service condition on a satellite depending on the implementation
[07:54.270 --> 08:01.970]  for the satellite. So we'll jump in to the command replay first and discuss that attack
[08:01.970 --> 08:07.430]  vector. So in the real world, which is not what we're operating with this demonstration, we're
[08:07.430 --> 08:13.650]  operating within simulation, but in the real world you have your ground terminals antenna that
[08:13.650 --> 08:18.790]  sends a RF signal to a satellite. So in the real world, if you were to do a command replay attack,
[08:18.790 --> 08:24.530]  you would need some sort of sniffing device to sniff the RF signal from the ground antenna
[08:24.530 --> 08:29.990]  while it's transmitting the uplink to the satellite. Well, in our simulated world,
[08:29.990 --> 08:35.710]  because we're using some high fidelity simulation capabilities that have been built that we can use
[08:35.710 --> 08:40.350]  simply UDP gets translated from the antenna to the satellite. So we're not,
[08:40.350 --> 08:45.730]  you know, sending RF signals from a ground station to a simulated satellite. Although you could do
[08:45.730 --> 08:51.650]  that, but for our purposes, we're going to use a simulator that just essentially takes the
[08:51.650 --> 08:58.230]  TCP IP traffic from the front end processor and then it translates it to UDP and then sends it
[08:58.230 --> 09:04.050]  to a spacecraft simulator that's running. So if we're doing that with UDP, then we can obviously
[09:04.050 --> 09:09.370]  use something as simple as TCP for our research. So that's, that's, that's kind of how we're set
[09:09.370 --> 09:16.250]  up. So this is the simulator that we're using, and it's, it's got some real components to it.
[09:16.930 --> 09:22.590]  That's, you know, runs in operations today for various missions that are flying. So
[09:22.590 --> 09:27.530]  there's a ground software component, there's a front end processor, there's the ground station
[09:27.530 --> 09:33.710]  sim that is used to translate the information to UDP, and then that sends it to the spacecraft
[09:34.410 --> 09:41.510]  that has a dynamic simulator with it. So we're using real ground software in this simulation.
[09:41.510 --> 09:45.190]  We're using real front end processor software. None of these have been modified. They're using
[09:45.190 --> 09:50.290]  the same software baselines as operational missions are using. It uses the same communication
[09:50.290 --> 09:58.070]  protocols, CCSDS, TC and AOS. So you can google those if you want to learn more about it. We'll
[09:58.070 --> 10:02.850]  get a little bit more into that detail later. But we aren't using any type of encryption,
[10:02.850 --> 10:06.530]  so there's no point-to-point encryption or bulk encryption anywhere in this.
[10:06.810 --> 10:11.110]  And we'll explain why, because that's the point of the demonstration is to show when you don't
[10:11.110 --> 10:17.610]  have encryption what can happen. We have some real flight software that runs on several operational
[10:17.610 --> 10:23.910]  missions currently, but it's cross-compiled for Linux. So it's not running on an embedded
[10:23.910 --> 10:31.050]  processor, a power PC, or an arm, or some FPGA. It's running just in Linux for our purposes,
[10:31.050 --> 10:38.070]  because we're just focused on the software testing at this point and not being too high fidelity.
[10:38.070 --> 10:42.350]  But there are technologies that exist where you can get super high fidelity, and we've used those
[10:42.350 --> 10:51.130]  in the past for several things. Things like Simix, or QEMU, or TCM. These are different
[10:51.130 --> 10:57.710]  technologies that you can use to have higher fidelity simulations to run software compiled
[10:57.710 --> 11:02.630]  for target. So those can be integrated in these simulators as well. So the ground station sim is
[11:02.630 --> 11:07.690]  kind of what mimics the RF transmission for us, but for us it just translates to UDP as I said
[11:07.690 --> 11:14.430]  earlier. So there's a simulation that's out there called 42 that's put out by NASA that helps do the
[11:14.430 --> 11:19.870]  attitudes, orbit dynamics, and environmental models. So that helps us understand the orbit
[11:19.870 --> 11:26.830]  and how we're progressing there. So here we go. And you can build your own one of these
[11:26.830 --> 11:32.310]  with some sources from GitHub. So these are linked here, OpenSATKit and NOS3 have some great
[11:33.170 --> 11:36.370]  components that you can construct something similar for yourself.
[11:37.010 --> 11:42.510]  Okay, so for our specific demonstration for command replay, our satellite in this scenario
[11:42.510 --> 11:48.370]  orbits the earth and is scheduled to uplink, downlink when it's over top of three different
[11:48.370 --> 11:54.650]  ground sites. One in California, one in Spain, one in Australia. So one would be Australia's in
[11:54.650 --> 12:01.950]  Canberra, Spain, Madrid, California, out near LA. So the point of our demonstration is we're going to
[12:01.950 --> 12:07.090]  capture the UDP traffic with TCP dump as it's leaving the ground station during the uplink pass.
[12:07.090 --> 12:13.590]  So this mimics an RF sniffing capture. And then we're going to replay that with TCP replay. So
[12:14.470 --> 12:21.450]  we did a quick, you know, Google search on the internet looking for what type of hardware and
[12:21.450 --> 12:27.250]  technologies needed to reproduce this type of an attack in real life. And basically it's
[12:27.250 --> 12:33.550]  around $7,000 and you could get some equipment that could record, capture, and transmit signal
[12:33.550 --> 12:39.190]  to a lower orbit. So it's definitely achievable for, you know, people who have a little bit of
[12:39.190 --> 12:43.090]  money. But then with the advent of some of these new technologies that are coming out today, like
[12:43.090 --> 12:48.150]  AWS Ground Station, the barrier could be much lower. So you may not need so much equipment,
[12:48.150 --> 12:54.550]  you may need sniffing capabilities, but we're a little unsure on what practices are going to be
[12:54.550 --> 12:59.490]  in place for AWS in the future. So to prevent, you know, these type of things from happening. But
[13:00.270 --> 13:06.670]  with that being said, it's just trying to articulate that the barrier for doing, you know,
[13:06.670 --> 13:14.450]  communications to a vehicle is getting less and less. Okay, so setting up the attack. So
[13:14.450 --> 13:21.510]  in our simulation, the satellite is visible to the ground station over the Madrid ground station. So
[13:21.510 --> 13:28.470]  it's there. And then in the bottom middle here, you see a signal lock in that window, it says,
[13:28.470 --> 13:32.810]  okay, it's locked, it's acquired. So it's sending the connect message, and then it's uplinking the
[13:32.810 --> 13:37.690]  command. So you see several commands being transmitted. You know, that's a bunch of
[13:37.690 --> 13:42.690]  numbers there. But what that does is you look in the far right, you see the flight software
[13:43.390 --> 13:47.990]  that's running. That's the, you know, that's kind of like the UART window of a flight software,
[13:47.990 --> 13:53.050]  where you have the flight software responding. You see it processes these NOOP commands. So
[13:53.050 --> 13:59.070]  in this example, we just hit some simple NOOP commands, which is kind of like a ping, you know,
[13:59.070 --> 14:05.650]  in our terminology. So just to see if the application running on board is alive. So
[14:05.650 --> 14:09.910]  upon receiving that command, the flight software indeed does process that command and downloads
[14:09.910 --> 14:14.490]  the event messages, and the command counters increment. So you see here in the ground,
[14:14.490 --> 14:19.830]  you see that the event messages are processed. It says, hey, there was a NOOP command, and it's
[14:19.830 --> 14:24.130]  downlinked to the ground. And then you see the command counters increment accordingly. So you
[14:24.130 --> 14:30.630]  see that the CMDPC, which is short for command processed, for each of those applications that
[14:30.630 --> 14:37.510]  were sent commands processed to increment to one was zero. So it goes to one. Now the satellite
[14:37.510 --> 14:43.550]  in our scenario is in transit between Madrid and Canberra. And you see in the ground station
[14:43.550 --> 14:49.050]  simulation that it's lost signal. So it's no longer in view. So now here's where we could actually
[14:49.050 --> 14:54.710]  do our replay attack. So in a real world scenario, you would need equipment, obviously, in the Madrid
[14:54.710 --> 15:01.130]  area to capture the RF traffic. And then somewhere over India, in this example, you would need
[15:01.130 --> 15:06.650]  transmit capability to be able to send transmit the information to the satellite. So in our
[15:06.650 --> 15:12.390]  scenario, it's a lot easier, obviously, because we're using just the TCP replay. And here's just
[15:12.510 --> 15:18.310]  a simple command. It replays the PCAP file that was captured. And then you see the flight software
[15:18.310 --> 15:25.610]  respond accordingly with the same event messages within the UART. But what you don't
[15:25.610 --> 15:31.730]  see is any event messages on the ground station because you were in between passes at that point.
[15:31.730 --> 15:38.130]  And the command counters, you notice when you establish the downlink again over Canberra that
[15:38.130 --> 15:42.990]  the command counters went up. So the flight software is reporting, hey, I received another
[15:42.990 --> 15:49.910]  command and, you know, in between ground passes, which would be odd. So from a, you know, defensive
[15:49.910 --> 15:55.790]  cyber operations perspective on the ground or, you know, C&D perspective, if you're not
[15:55.790 --> 16:02.430]  monitoring certain key telemetry points on your vehicle, you may not be aware that, you know,
[16:02.430 --> 16:09.550]  someone has tried to make a connection or send commands. So it's very important to understand
[16:10.110 --> 16:16.190]  what the telemetry values are that you could be monitoring that could provide you insight
[16:16.190 --> 16:20.910]  into potential attack vectors. So there's a lot of telemetry points out there that could help with
[16:20.910 --> 16:28.410]  that. So that wraps up the command replay. So essentially what we did was capture the command
[16:28.410 --> 16:35.710]  link up and then we replayed it and we saw that it processes. So we'll move on to command
[16:35.710 --> 16:40.950]  link intrusion, which is a little bit different. It's a slight different take on a command
[16:42.250 --> 16:48.010]  command link attack. So since there's no encryption in our environment, our simulated
[16:48.010 --> 16:53.850]  environment here, and there's no authentication, theoretically, the thought was, well,
[16:53.850 --> 16:59.250]  if you just inspect the traffic and understand the packet structure and understand
[16:59.770 --> 17:03.590]  what information is in there, theoretically, you could craft your own packet that matches that
[17:03.590 --> 17:07.390]  structure and just send it up and see if it processes the command. So you're not really
[17:07.390 --> 17:13.490]  replaying anything. You're just constructing your own raw command packet and then uplinking it and
[17:13.490 --> 17:20.250]  seeing what happens. So let's try that out and see how it works. So once you've inspected the
[17:20.250 --> 17:24.670]  traffic and understand there's no encryption, you see in one of the telemetry values, and you
[17:24.670 --> 17:31.030]  can obviously do this with RF as well. You can record the RF on the downlink and record it as
[17:31.030 --> 17:36.130]  well. But you see, once you have the information and you see here in the middle, you see CFE,
[17:36.130 --> 17:46.770]  TBL, NOOP, CFE version 6.6.0.0. So you see that information there and that implies that they're
[17:46.770 --> 17:52.910]  using CoreFlight executive or CoreFlight software. And so then you can say, well, that's available on
[17:52.910 --> 17:59.210]  GitHub, I believe. So this is where that comment about default configs really comes into play.
[17:59.210 --> 18:06.730]  So you go look on GitHub and you understand that CFE CFS uses the CCSDS protocol. So then you get
[18:06.730 --> 18:13.790]  into this research study on command packet structures, which is a fun study.
[18:13.790 --> 18:19.090]  I would not recommend it for people if they're not really interested in it because
[18:19.090 --> 18:25.370]  it's a little bit of a read. So we're looking, we start to break down how
[18:25.370 --> 18:30.750]  these systems work from a protocol perspective. So we have space packets and then we're
[18:30.750 --> 18:37.550]  gonna get into some really space buzzword bingo here. So I apologize for that. But for the people
[18:37.550 --> 18:43.770]  who know what this is, you'll get it. But for the people who don't know, forgive me
[18:43.770 --> 18:48.390]  for kind of speaking in this lingo, but the space packets get wrapped in these transfer frames
[18:48.390 --> 18:51.750]  and then the transfer frames are wrapped in what's called these command link
[18:51.750 --> 18:57.730]  transmission units, CLTUs. So that's kind of how this structure works is CLTU, transfer frame
[18:57.730 --> 19:04.630]  headers, space packet, and then the trailers. So then we start looking in the CCSDS protocol
[19:05.470 --> 19:11.130]  and we understand, okay, this is the space packet. These are the octets that are there.
[19:11.130 --> 19:16.750]  And then we start really diving into some of these documents and we say, okay, well, this is
[19:16.750 --> 19:21.170]  what the primary header is. This is what a transfer frame looks like. This is what the transfer frame
[19:21.170 --> 19:25.590]  primary header looks like. This is what the CLTU looks like. And then so we're kind of in this
[19:25.590 --> 19:32.810]  overload of terminology, protocol breakdown, things like that. So it gets a little cumbersome
[19:32.810 --> 19:38.610]  and confusing, but it's important to understand all these things. And it's also important to
[19:38.610 --> 19:43.610]  realize that these protocols are open source protocols. So a lot of the, a lot of missions,
[19:43.610 --> 19:49.590]  spacecraft that are out there today, leverage CCSDS because that is an international standard
[19:49.590 --> 19:56.470]  that the CCSDS group is a consortium of many space agencies from across the world who get
[19:56.470 --> 20:03.710]  together and standardize on protocols and things like that. So it's easy. You just kind of, you
[20:03.710 --> 20:07.470]  can just Google the standards and find them and they'll have these diagrams in there and you can
[20:07.470 --> 20:13.650]  break down, you know, the bit patterns and things. So from our transmission, since there's no encryption
[20:13.650 --> 20:20.750]  on that, you just basically have the raw number structure. And to the, to the kind of uninformed,
[20:20.750 --> 20:25.970]  this looks just like a bunch of gibberish, but what we're going to do is take the knowledge we
[20:25.970 --> 20:34.010]  gained from reading the hundreds and hundreds of pages of those CCSDS protocols and see what
[20:34.010 --> 20:41.130]  we can find out. So let's look here. We see the, the fives in our scenario is the acquisition
[20:41.130 --> 20:48.210]  sequence. And then we've determined where the CLTU is. So we've now, we've got the CLTU. So let's
[20:48.210 --> 20:52.770]  break that down and see what we can get. So then we take off the headers and trailers in this
[20:52.770 --> 21:00.430]  example. And then now we have this subset, and then we have this code blocks and these check
[21:00.430 --> 21:06.050]  bytes, and we take those out. So now we've identified the actual TC transfer frame, which is,
[21:06.050 --> 21:12.350]  which is where the, the command information is stored on, on the uplink. So now we've got that.
[21:12.350 --> 21:17.890]  So let's take out the header on that. And now we have the command packet. So this is the one
[21:17.890 --> 21:22.770]  that we were looking for. So with all those numbers, this is really what we were looking
[21:22.770 --> 21:26.690]  for. We're looking for this command packet, because it's going to tell us hopefully what
[21:26.690 --> 21:32.550]  kind of command was sent up on that uplink. So from that, from the telemetry stream, we've kind
[21:32.550 --> 21:39.770]  of discussed, we see this no op command that came down. So we've, we look on the GitHub repo, and
[21:39.770 --> 21:47.230]  we've realized that in our example, that the spacecraft that's we're looking at seems to be
[21:47.230 --> 21:53.530]  using these default command and telemetry IDs. So because if you look at the, the header file for
[21:53.530 --> 22:02.010]  the message IDs, for the CFE table, command message ID, you see 1804. So that would indicate
[22:02.010 --> 22:09.210]  like the high likelihood of actually the software's using these default message ID types.
[22:09.210 --> 22:13.790]  So what that does is allow you to basically transmit information to the, you're going to
[22:13.790 --> 22:18.470]  try to transmit information using this knowledge you've gained to the simulated spacecraft to see
[22:18.470 --> 22:24.470]  kind of what will happen. So let's see if we can, we can reconstruct a packet with this knowledge
[22:24.470 --> 22:28.990]  and see what we can do with it. So with this knowledge, let's play around a little bit and
[22:28.990 --> 22:33.590]  see what we can do. So we've got our knowledge of the command structure from GitHub, and since we
[22:33.590 --> 22:37.650]  can't construct a new command, maybe something else to see what happens, just to see if the
[22:37.650 --> 22:42.570]  command, the spacecraft will actually process it. So you have to do a little digging and understand
[22:42.570 --> 22:47.850]  the functionality of this software, but luckily all that information is open source. So
[22:47.850 --> 22:52.650]  once you dig in a little bit, you see, you notice there's this functionality within
[22:52.650 --> 23:00.730]  the CoreFlight software called ES. It's an ES application where you can potentially, you know,
[23:00.730 --> 23:04.730]  have control over the applications on board. So we're going to see if we can reconstruct a packet
[23:05.290 --> 23:10.790]  to do a reboot of a particular application. So in the real world, you know, you would have to
[23:10.790 --> 23:16.550]  reverse engineer the packet structure of the RF signal. But in our scenario, we're going to
[23:16.550 --> 23:21.490]  transmit the UDP packet with the following information and see if we can get a reset of
[23:21.490 --> 23:29.090]  one of the applications. So we use that 1806 because that's the default message ID for the
[23:29.090 --> 23:35.570]  ES application. So that tells the flight software, hey, this command is meant for the ES application
[23:35.570 --> 23:41.570]  to process once it gets on the satellite. And then the rest of the numbers is just,
[23:41.570 --> 23:47.550]  you know, understanding the... translating the command and telemetry database into this format,
[23:47.550 --> 23:51.010]  which I won't bore you with all the details that had to happen for that to occur, but
[23:52.270 --> 23:57.050]  you can get there, essentially. It just takes a while to figure out what the structure is and
[23:57.050 --> 24:01.910]  what numbers need to go where and what those values need to be. So let's send this raw packet
[24:01.910 --> 24:09.350]  up and see what we can do. So we send that raw packet up to the satellite and look at that. So
[24:09.350 --> 24:16.270]  we see in the UR of the actual flight software that we have some sort of response. So you see
[24:17.010 --> 24:23.570]  at the top of the window, you see CFE ES restart app initiated for HK. So it looks like it was
[24:23.570 --> 24:29.710]  successful. So we essentially have reconstructed our own packet based on information that we've
[24:29.710 --> 24:37.230]  gained from GitHub and then transmitted it to our spacecraft simulator and it indeed did process it.
[24:37.230 --> 24:43.090]  So that's an example of, you know, a command-link intrusion where you've basically put your own
[24:43.090 --> 24:48.150]  command structure and sent it up and got it to process. So that's kind of the response. So
[24:48.830 --> 24:54.670]  the question is like, okay, why does the replay attack work? Why does this command-link intrusion
[24:54.670 --> 25:00.210]  attack work? So part of it's the open sourceness of the information out there so you can pull
[25:00.210 --> 25:06.390]  that data from GitHub and do your own research. But it really gets down to the protocols and some
[25:06.390 --> 25:12.770]  of the protections. So in this example, there's a communications operational procedure that
[25:12.770 --> 25:20.610]  typically runs on a satellite, at least ones that operate CCSDS called COP1. And that helps
[25:20.610 --> 25:26.170]  with sequencing to make sure that the sequence of the commands and the packets received are
[25:26.170 --> 25:33.070]  proper. On our example, COP1 wasn't turned on by design in our example, but
[25:33.070 --> 25:39.850]  there's a lot of actual spacecraft who don't leverage COP1 for various reasons. So COP1 would
[25:39.850 --> 25:45.710]  have provided some level of protection, but that can be fudged and gotten around if you know what
[25:45.710 --> 25:53.010]  you're doing. So in example, I redid the same example for replay with COP1 enabled, and you see
[25:53.010 --> 25:57.370]  here that the command is not processed because they were out of sequence. So I could have really
[25:57.370 --> 26:04.470]  fudged the data around with sequencing and probably got the process, but we didn't
[26:04.470 --> 26:08.750]  really want to get into that. But the point was just to articulate that there are sequencing
[26:08.750 --> 26:16.590]  protections that you can put in to help with the replay. But the real control that
[26:16.590 --> 26:22.110]  you want is encryption and authentication. So you really need to encrypt and authenticate
[26:22.650 --> 26:28.370]  the command link. So it's not enough to just do encryption because you theoretically
[26:28.370 --> 26:35.170]  could just replay an encrypted link and it would process accordingly. So you need the authentication
[26:35.170 --> 26:39.830]  on the command link as well. So that's important. So you need both. So to properly protect
[26:39.830 --> 26:45.930]  from a replay or an intrusion attack, like here are some just guidelines for
[26:47.250 --> 26:51.130]  pseudo requirements, sample requirements about cryptography and authentication. So you need to
[26:51.130 --> 26:58.350]  authenticate and you need to do cryptography to ensure that these attacks won't work. Okay, so now
[26:58.350 --> 27:06.230]  we're going to jump into denial of service via GPS jamming. So the first two were particularly
[27:06.230 --> 27:11.910]  to the command link. So those were intrusion and replay. This one's a little bit different
[27:11.910 --> 27:15.910]  and it's going to use a different simulator, but we won't get into the specifics on the sim, but
[27:15.910 --> 27:21.910]  it's a high fidelity simulator that has a lot of dynamics and a lot of command and data handling
[27:21.910 --> 27:28.130]  and GNC capabilities. So what we're going to do is get the vehicle in an operational
[27:28.130 --> 27:34.910]  state where it's doing a mission operations, and then we're going to simulate the
[27:34.910 --> 27:39.890]  denial of service with GPS signal, which is basically cut off the GPS, and then we're going to see how the
[27:39.890 --> 27:46.930]  system responds. So jamming, for those who aren't necessarily aware, is the intentional
[27:46.930 --> 27:51.210]  or sometimes unintentional interference of the signal that prevents it from being received. So
[27:51.210 --> 27:58.670]  it's relatively simple to do. It's easy to overpower at close range and jammers can be
[27:58.670 --> 28:04.030]  on the ground, it could be in the ocean, airspace, jammers can be about anywhere. So in our scenario,
[28:04.030 --> 28:09.010]  the spacecraft simulator is set up to be in what's called mission science mode or operational mode,
[28:09.010 --> 28:14.130]  and once it reaches this mode, we're going to simulate the GPS signal by stopping the flow
[28:15.010 --> 28:22.110]  on the space wire bus, which is where the GPS sends its data to the Singapore computer,
[28:22.110 --> 28:29.510]  the flight software. So here is just a graphical representation of some of the telemetry and
[28:29.510 --> 28:36.210]  dynamics data for this particular sim as it's operating. And we are, you know, it shows,
[28:36.210 --> 28:43.690]  you see the attitude control mode previous to attitude control mode current, which is MSM,
[28:43.690 --> 28:47.730]  which is the mission science, which is the operations mode. So what we're going to do here
[28:48.290 --> 28:53.510]  is we're going to block that data from getting to the Singapore computer, the flight software
[28:53.510 --> 28:57.650]  from the GPS sensors, and we're going to see what happens. So in the middle here, you see
[28:57.650 --> 29:04.830]  the GPS data packet counts increasing. So you see it go from 920 to 944. So everything's optimal
[29:04.830 --> 29:12.310]  here. We're operating, we're flying in orbit, GPS signal is being processed, and everything is fine.
[29:12.310 --> 29:19.050]  So here, now we're going to, in our simulation, we're going to basically leverage a capability
[29:19.050 --> 29:25.170]  that was built into the simulator to block data across the Spacewire bus based on whichever
[29:25.750 --> 29:30.030]  values we want. So we can block about anything that's flowing across the Spacewire bus,
[29:30.030 --> 29:37.670]  or 5053 bus for that matter, and see what happens. So once you initiate this block sequence,
[29:37.670 --> 29:43.290]  you see the ground telemetry values freeze. So you see, which indicates the gray background there.
[29:43.290 --> 29:48.550]  So at this, the ground station is reporting, hey, I don't, I'm not receiving GPS data anymore.
[29:48.550 --> 29:52.730]  For some reason, it's not being downlinked. And that's because it's not being actually
[29:52.730 --> 29:59.070]  provided to the Singapore computer for downlink. So you see that freeze. So, and you know,
[29:59.070 --> 30:07.070]  for spacecraft, you know, one thing to understand is, you know, you can't, you can't go up there,
[30:07.070 --> 30:11.970]  you can't like a, obviously a real computer, go, you know, hit the reset button. There's a lot of
[30:11.970 --> 30:14.930]  autonomy built in, there's a lot of fault management, and a lot of testing goes around
[30:15.150 --> 30:22.630]  fault management response. So what you should know is like, typically, when you have a
[30:22.630 --> 30:29.450]  satellite in orbit, and some anomalous thing happens, the last-ditch effort to save it
[30:29.450 --> 30:33.410]  basically is to go into what's called a sun pointer safe mode. So it basically takes the
[30:33.410 --> 30:38.470]  solar arrays and points it to the sun and says, I'm just going to hang out here until I hear
[30:38.470 --> 30:44.050]  from the people who control me in the ground station. So what we're going to do here is
[30:44.050 --> 30:49.850]  see what the autonomous flight response is once the GPS signal is blocked. So safe mode
[30:49.850 --> 30:55.670]  is an operational mode, where a lot of non-essential systems are shut down. It's very similar to
[30:56.210 --> 31:01.630]  Windows, you know, when Windows goes in safe mode, it shuts off a lot of the features of
[31:01.630 --> 31:07.350]  Windows from that perspective. So preservation of the spacecraft is the highest priority. So
[31:07.860 --> 31:14.890]  here you see in the downlink telemetry, the flight software is starting to do its
[31:14.890 --> 31:21.570]  autonomous fault management. It's running what are called RTSs, so relative time sequences.
[31:21.570 --> 31:25.110]  So these are things, these are just automated flight responses that are there.
[31:25.210 --> 31:30.210]  And it's starting to do various things, it's doing movements, it's stopping
[31:30.210 --> 31:34.990]  antennas, it's transitioning to some point mode from an attitude control perspective. So it's
[31:34.990 --> 31:40.330]  starting to safe itself. And in the telemetry you see from the attitude control mode perspective,
[31:40.330 --> 31:47.170]  it's reached its desired some point state at this point. So why would you perform a denial
[31:47.170 --> 31:54.170]  service, you know, like GPS jamming on something? So, you know, maybe you're just wanting to have
[31:54.270 --> 31:58.110]  a little fun, maybe you're just trying to disrupt and degrade some sort of mission operations for
[31:58.350 --> 32:03.350]  a specific time. Maybe you're wanting a mission to not achieve any objectives. But what if you're
[32:03.490 --> 32:06.990]  a little bit smarter than that? And you understand the autonomous fault response
[32:07.450 --> 32:11.130]  for satellites, and you understand the design and fault management a little bit more. So
[32:12.170 --> 32:17.350]  a more strategic, you know, attacker understands that there's a lot of autonomous fault response
[32:17.350 --> 32:21.850]  for a mission to put itself in a really safe state. So if you just think about the safe mode
[32:21.850 --> 32:26.610]  for Windows, you know, a lot of the security features get disabled while you're in safe mode.
[32:27.270 --> 32:32.710]  Similar things do happen for spacecraft. So forcing a spacecraft into safe mode
[32:32.710 --> 32:39.110]  could potentially open up additional vectors that aren't there. So think about a, you know, maybe
[32:39.730 --> 32:45.250]  if you've jammed the GPS signal, maybe your fault management response is to save yourself,
[32:45.250 --> 32:51.770]  turn off cryptography, you know, and open up your command link for any signal that you can process.
[32:51.770 --> 32:57.710]  Just depends on the fault management response. That's a design decision. But just think about
[32:57.710 --> 33:03.210]  that as you're doing your design that you may not think through, like, hey, maybe adversaries may
[33:03.210 --> 33:08.010]  know that I can be more vulnerable, get put in a more vulnerable state. So maybe I need to
[33:08.010 --> 33:13.690]  design in something, you know, the terminology that we put in the paper that was linked in the
[33:13.690 --> 33:20.190]  front, defending the spacecraft in the cyber domain paper. We talk about the cyber safe mode.
[33:20.190 --> 33:26.750]  That's a slight transition from the traditional safe mode terminology. But it's basically
[33:28.150 --> 33:34.130]  it's a safe mode that's cyber hardened to a degree. And you have a high integrity
[33:34.910 --> 33:38.890]  mode that you're in, that you know you're in a good state and everything's valid,
[33:38.890 --> 33:45.830]  and you still have authentication encryption going on. So that's a concept. That's a kind
[33:45.830 --> 33:52.550]  of newer concept that's being discussed in the space sectors. But it should be there. Because
[33:52.550 --> 33:57.430]  knowing, you know, more and more people that understand space and understand fault management
[33:57.430 --> 34:02.150]  response may use that against you. So you may want to think about that a little bit more as
[34:02.150 --> 34:08.110]  you do your design. So here's some recommendations for just generalized protection. This isn't
[34:08.110 --> 34:12.730]  specifically GPS jamming because there's a whole there's papers upon papers out there that talk
[34:12.730 --> 34:18.350]  about how to protect against jamming. But this is more in line with protecting against, you know,
[34:18.350 --> 34:22.070]  leveraging fault management against you. So you need to really protect that documentation
[34:22.650 --> 34:26.430]  because that's just basically providing an adversary a pathway to get you in a more
[34:26.430 --> 34:33.470]  vulnerable state if your design is built that way. And other design considerations about always
[34:33.470 --> 34:39.570]  encrypting information, especially on the downlink. So some people think that the downlink on the
[34:39.570 --> 34:44.410]  telemetry side should not necessarily be encrypted because it's not, you know, it's not controlling
[34:44.410 --> 34:49.430]  the vehicle. But there could be a lot of good information that is ascertained from telemetry.
[34:49.430 --> 34:53.450]  So it could be you could have adversaries monitoring your telemetry stream looking for
[34:53.850 --> 35:01.190]  various, you know, indicators that you are in a less secure state. And these are other
[35:01.190 --> 35:05.030]  some design considerations that are that are here. I won't read them all to you. But basically
[35:05.030 --> 35:10.390]  getting, you know, the cyber safe mode, getting, you know, only report error messages when needed
[35:10.950 --> 35:15.250]  and encrypting it accordingly and getting make sure you have ability to recover and reconstitute
[35:15.250 --> 35:20.430]  to a known state. So these are just some considerations to think about as you're
[35:20.430 --> 35:27.230]  building your design for a spacecraft. So with that being said, those are just an example of
[35:27.230 --> 35:33.570]  doing some protection. So let's talk about what it takes to let's transition the discussion a
[35:33.570 --> 35:39.450]  little bit and talk about what it takes to just protect the overall ground system. So at this
[35:39.450 --> 35:47.610]  point, we've talked about, you know, the command link intrusion. We've talked about command replay,
[35:47.610 --> 35:52.530]  some denial of service. But let's talk more generically about space systems in general. So
[35:53.150 --> 36:01.010]  I like to use defense in depth as a presentation material and discuss and a principle for design
[36:01.010 --> 36:05.930]  as many people do. I mean, I think anyone in the security community really understands the
[36:05.930 --> 36:12.230]  fits and depth. But with the fits and depth, I like to illustrate basically using an onion. So
[36:12.230 --> 36:18.070]  in the typical, you know, IT sense, the onion diagram, you have, you know, the hardened server
[36:18.070 --> 36:24.010]  configuration wrapped with intrusion prevention firewall type stuff. But in the space domain,
[36:24.010 --> 36:28.190]  it's a little bit different, but it's somewhat similar. But so here's some graphics that I wanted
[36:28.190 --> 36:33.790]  to provide that give you a representation of the fits and depth for both ground and space. So
[36:34.650 --> 36:40.110]  this first graphic here is kind of the ground system. So it starts with the data that runs,
[36:40.110 --> 36:47.290]  you know, on the endpoints, wrapped by software, supported by endpoints, connected by networks,
[36:47.290 --> 36:51.430]  protected by intrusion detection and perimeter controls and physical controls. So there's,
[36:51.430 --> 36:58.170]  you know, this isn't all inclusive, not every subcategory, you know, within each block is listed.
[36:58.190 --> 37:04.690]  Due to space, but it provides a good list of things that you would expect to be at each
[37:04.690 --> 37:10.670]  layer of the onion. So from a data perspective, you may have, you know, data at rest encryption,
[37:10.670 --> 37:16.010]  you may have Tempest that you need to worry about. From a ground software perspective, you know,
[37:16.010 --> 37:22.370]  SDLC, secure coding, common weakness enumeration prevention, things like that, binary analysis,
[37:22.370 --> 37:28.810]  dynamic analysis, static code analysis, stuff like that. Your endpoints, your heads, your hips,
[37:28.810 --> 37:34.010]  your AV malware, DLP, file integrity, things like that. So we won't dive into every one of these,
[37:34.010 --> 37:38.370]  but it's kind of important to understand that you can pick and choose to apply controls at
[37:38.370 --> 37:43.090]  each layer. And it's important to apply controls to each layer. So you don't want to just put all
[37:43.090 --> 37:48.650]  your eggs in the perimeter basket and say, I'm going to stand up a good DLP, a good firewall,
[37:49.290 --> 37:55.730]  and security zones on the perimeter. And then hope that gets me there because you have insiders,
[37:55.730 --> 38:00.150]  you have other avenues where you need monitoring capability, you need protections.
[38:00.310 --> 38:05.370]  So that's pretty common. You know, that's nothing groundbreaking from a ground perspective. But
[38:05.370 --> 38:10.130]  similarly, you can do the kind of the exact same approach for the vehicle itself. So
[38:10.730 --> 38:15.290]  this is a onion representation for the vehicle. So you have, you know,
[38:15.290 --> 38:20.510]  similarly the data that's on board the vehicle, wrapped and processed by some sort of software
[38:20.510 --> 38:27.130]  on board that has a single board computer or, you know, a processor and a bus,
[38:27.130 --> 38:31.970]  hopefully protected by some sort of onboard intrusion detection prevention. So that's kind
[38:31.970 --> 38:37.550]  of a new area. What's being researched today is kind of onboard cyber monitoring and intrusion
[38:37.550 --> 38:44.070]  detection prevention. That's not typical on a lot of missions right now. What you see currently,
[38:44.170 --> 38:49.830]  a lot of the focus on protecting space vehicles is really geared around the crypto comms area.
[38:49.910 --> 38:58.290]  So, you know, the authentication encryption and the comms link, the transect, things like
[38:58.290 --> 39:03.450]  that. But there are controls that you can apply and there are threat vectors that exist for
[39:03.450 --> 39:09.290]  basically every one of these blocks on the vehicle as well as on the ground. So
[39:09.930 --> 39:14.770]  since there's threats and vulnerabilities that can be exploited, that can happen on
[39:14.770 --> 39:17.790]  kind of each block, it's important to put controls in each block, honestly,
[39:17.790 --> 39:24.810]  so that you can have a better chance of protecting yourself. So in conclusion,
[39:24.810 --> 39:28.670]  we've talked, you know, kind of three attack vectors, but those are just three
[39:28.670 --> 39:35.470]  examples and there's many more that can be discussed. But it's kind of convenient,
[39:35.970 --> 39:43.070]  to ignore security, honestly, because there's not been this, you know, windfall of
[39:44.150 --> 39:49.970]  events that have happened that are cyber related on a vehicle. But it's not really an option moving
[39:49.970 --> 39:56.250]  forward. Satellites are too critical to our everyday life or operations of our nation and
[39:56.250 --> 40:01.690]  the world, honestly. And it's kind of important to understand that the barrier to entry into space
[40:01.690 --> 40:07.630]  has been dramatically reduced in the last five, 10, 15 years. I mean, with small sats and launch
[40:07.630 --> 40:16.390]  services, and AWS ground stations, it's getting real easy to get a lot cheaper to get information.
[40:17.050 --> 40:24.310]  It's a lot cheaper to get assets into space. So, and defensive depth needs to be a big part
[40:24.310 --> 40:28.390]  of the solution. So we need to design security at the beginning, which is kind of cliche, but
[40:28.390 --> 40:34.350]  obvious. And it's going to be more and more important as we, you know, start to deploy all
[40:34.350 --> 40:39.850]  these small sats in a peripheral-related constellation moving forward. So, you know,
[40:39.850 --> 40:44.970]  from a defense in depth perspective, and, you know, understanding security, it's important. So
[40:44.970 --> 40:49.710]  I mean, there's a little bit of a interesting parallel you can draw, you know, with space
[40:49.710 --> 40:56.670]  systems, and in the industrial control system arena. So it's, you know, for years and years,
[40:56.670 --> 41:02.730]  you see this at, you know, at the IoT village as well. For years and years, people have kind
[41:02.730 --> 41:08.590]  of ignored security in the industrial control systems, OT, IoT arena. And it's not just been
[41:08.590 --> 41:13.970]  the last few years, people have really started understanding that threat factor. And, and
[41:13.970 --> 41:19.270]  mainly it's due to, there's been documented attacks, and a lot of bad things have happened
[41:19.270 --> 41:23.950]  as a result of that. So let's try to learn from that lesson and not wait till something really bad
[41:23.950 --> 41:28.810]  happens to make corrections. Because we know there are vulnerabilities, we know there are
[41:28.810 --> 41:35.390]  corrections, we know there are things we can do. So we should be doing that. And the small set
[41:35.390 --> 41:39.870]  marketplace, you know, and the embedded security community is evolving. There's a lot of commercial
[41:39.870 --> 41:45.590]  things that are being put out, there's some open source solutions that are out there. And we need,
[41:45.590 --> 41:50.830]  you know, accountability, we need people who are researching this to understand the security
[41:50.830 --> 41:57.150]  ramifications of these things and, and need to be somewhat agile to get these things verified
[41:57.150 --> 42:04.150]  and validated and accepted and put out in the community. As opposed to some niche areas,
[42:04.150 --> 42:11.430]  niche markets, people doing things. So it's important for us to get, you know, leverage the
[42:11.430 --> 42:19.270]  explosion in this market. But it's also, we need the security researchers and, you know, ethical
[42:20.230 --> 42:25.930]  hackers and things like that to really, you know, hold people accountable for the things we're
[42:25.930 --> 42:32.890]  putting out. Because, you know, the path of least resistance is often used. So if no one's looking
[42:32.890 --> 42:37.010]  at your, looking at your work and understanding the security ramifications of your design and
[42:37.010 --> 42:41.770]  what you're doing, you know, people kind of get lazy with their implementation at times. So it's
[42:41.770 --> 42:46.650]  important that we all get out there and research this stuff and look, look into it to understand
[42:46.650 --> 42:52.130]  the ramifications, some of these design choices that are being made. So we need to really, you
[42:52.130 --> 42:57.570]  know, the government industry, I think we're coming to a very good, you know, agreement that
[42:57.570 --> 43:02.430]  cybersecurity is super important for, for space programs. And there's a lot of investment that
[43:02.430 --> 43:07.930]  needs an education, training and talent development and retention. So I, I feel like there's a huge
[43:07.930 --> 43:12.530]  step forward this year at DEF CON with the hack-a-sat. I mean, that, that is a fantastic
[43:12.530 --> 43:18.590]  event that, you know, that's ongoing within the Aerospace Village to, to, you know, hack into
[43:18.590 --> 43:24.910]  to representative satellite systems. And it, you know, there's these open source technologies that
[43:24.910 --> 43:28.830]  are put out that you can build your own ground-to-space simulation. You can start learning.
[43:29.030 --> 43:35.110]  You know, five years ago, there was not that much out there to learn. So the, the activation energy
[43:35.110 --> 43:42.290]  and the level of access to information was, wasn't there for the security community to get
[43:42.290 --> 43:48.850]  into it. So I think it behooves us, you know, within the government, within the industry to start
[43:48.850 --> 43:52.910]  getting this information out there and making this stuff available for the researchers so they can,
[43:52.910 --> 43:58.650]  you know, we can find some of these vulnerabilities and get them fixed. And technology has evolved
[43:58.650 --> 44:05.410]  from a simulation perspective so much in the last 10 years with the advent of, you know, digital twin
[44:05.410 --> 44:11.030]  type technology for space. The embedded arena is getting there, you know, with open source,
[44:11.030 --> 44:17.730]  things like QEMU, with commercial things like Simics or TCM, you can get really high fidelity
[44:17.730 --> 44:24.890]  simulators running software. And that's, you know, built for target and running a lot of tests. You
[44:24.890 --> 44:30.390]  don't have to buy these million dollar space platforms. And there, and also these, you know,
[44:30.390 --> 44:34.650]  these CubeSats that you can buy, and these embedded processors, you can buy some of these
[44:35.310 --> 44:38.330]  things kind of commercially off the shelf, start doing your own research if you have some of the
[44:38.330 --> 44:44.890]  budget. But the last point is, you know, the reason I wanted to do this presentation
[44:44.890 --> 44:51.450]  and be a part of the Aerospace Village and work with the Space Ice Act is information sharing
[44:51.450 --> 44:57.190]  is a must. I mean, coming from the government arena, you really get into this compartmentalization
[44:57.190 --> 45:03.330]  of information and the need to know and things like that. So, but we really need to have
[45:03.330 --> 45:07.910]  information sharing, we need to do research, we need to have events like this, the Aerospace
[45:07.910 --> 45:13.990]  Village, we need to come together as a community and start doing this research together. And we're
[45:13.990 --> 45:18.570]  not trying to point fingers at people and, you know, say that, oh, your implementation is bad.
[45:18.570 --> 45:24.730]  It's just we need to learn together and make things better and share what we learn and do
[45:24.730 --> 45:30.830]  presentations like this. So, with that being said, that's about all I have to present. But I do have
[45:30.830 --> 45:39.170]  here on slide 29 a link to some resources, the Space Ice Act, there for information on it,
[45:39.170 --> 45:45.990]  the HackASAT link. Something that's going to be really cool is they, the HackASAT was,
[45:45.990 --> 45:49.830]  you know, they had qualification rounds and they have the finals at DEF CON this year.
[45:49.830 --> 45:56.070]  And they're going to open source a lot of those CTFs qualifications and things. So keep an eye
[45:56.070 --> 46:01.990]  on the HackASAT URL to, you know, maybe pull down some of those CTFs once they get published
[46:01.990 --> 46:08.710]  and give them a try yourself and learn. This is a really exciting exercises that were put together.
[46:08.710 --> 46:14.010]  If you want to build some of your own simulators, these links are there with for OpenSATKit,
[46:14.510 --> 46:21.510]  Noscubed, 42, things like that, Open Source Flight Software, CPCFS. And there's some info here on,
[46:21.930 --> 46:25.470]  you know, jamming if you want to learn a bit more about that. And the paper that
[46:25.470 --> 46:33.390]  was published in November 2019 is also linked here for your reference. So with that being said,
[46:33.390 --> 46:39.130]  that is all I have to present. And thank you so much. And I'll take questions
[46:39.130 --> 46:41.890]  in the offline session. Appreciate it.
